Problem

Agent Deployments created through the kagent UI or CLI produce pod templates with empty securityContext at both pod and container level. On clusters that enforce the Kubernetes restricted Pod Security Standard (the recommended default since Kubernetes 1.25), admission rejects these pods before they start. Agents never become ready.

The kagent control-plane pods are already compliant, which makes this inconsistency confusing for users.

Fixes #2244

Root Cause

buildContainerSecurityContext returns nil when the Agent CR has no SecurityContext and code-exec isolation is not needed. buildPodTemplate passes dep.PodSecurityContext directly, which is also nil by default. The result is a pod spec with no security context at either level.

Fix

When the user does not supply security context fields, the controller now injects restricted-PSS-compliant defaults:

Container level:

• runAsNonRoot: true
• allowPrivilegeEscalation: false
• capabilities.drop: [ALL]
• seccompProfile: RuntimeDefault

Pod level:

• runAsNonRoot: true
• seccompProfile: RuntimeDefault

User-supplied values always take precedence. The existing base != nil path in buildContainerSecurityContext and the nil check in defaultPodSecurityContext preserve any explicit user configuration unchanged.

The code-exec isolation path (skills with sandbox) is also unchanged: when needCodeExecIsolation is true, the controller still sets Privileged: true as before.

Testing

• Updated TestSecurityContext_OnlyPodSecurityContext to verify that the container now receives restricted defaults instead of nil
• Updated TestSecurityContext_OnlyContainerSecurityContext to verify that the pod now receives restricted defaults instead of nil
• Added TestSecurityContext_NilSecurityContext_RestrictedDefaults covering the common case where no SecurityContext is set at all
• All 6 security context tests pass
• Existing tests for skills/sandbox (SkillsDefaultPrivilegedSandbox, SkillsPSSRestricted) continue to pass without modification